SD Times Issue 132 by BZ Media

Author:BZ Media
Language: eng
Format: epub
Tags: SD Times;
Published: 2005-08-14T16:00:00+00:00

alectric^ffcloud

OPINION

. Software Development Times . August 15, 2005 .

www.sdtimes.com

EDITORIAL

Building on Agility

Has it only been four years since the Agile Manifesto was created? Thanks to the manifesto, as well as best-selling books like Kent Beck's "eXtreme Programming eXplained" and Martin Fowler's "Refactoring: Improving the Design of Existing Code," agile methods have become increasingly popular.

Unfortunately, although the methodologies are popular, they're often misunderstood.

For many people, agile methodologies == Extreme Programming, or XP == programming in pairs. That concept seems to have stuck with many people as the sine qua non of agility, perhaps because it's controversial and doesn't have obvious benefits. It's also the biggest break with traditional processes.

Of course, there are more agile methodologies than Extreme Programming, and there's more to even XP than pair programming. Many agile methodologies call for designing the application using user stories, for close communication with customers, for frequent (or daily) builds, for incremental software releases, for coding unit tests prior to adding new functionality, and for constant refactoring.

Many of these goals, and those of all the agile methodologies, make perfect intuitive sense. How can you argue against encouraging your developers to communicate with customers, or against constant testing of new code?

Where agile methodologies have trouble can be in the execution of these principles.

Take the concept of frequent or continuous builds. While fine in theory, in practice this can be difficult for a nontrivial codebase. Without sophisticated build automation tools, the build process can be balky and temperamental. Yet, those build automation tools can be expensive to license and complicated to use—and even when they're present, the build might take a long time to execute.

For a small team and a small project, nightly builds aren't a problem. For a large, distributed development team working on a multilanguage, cross-platform application, where the build might take dozens of hours to execute, they're a potential bottleneck. Before embarking on a new agile project, be sure to analyze the impact that the project will have on your build systems.

Still, don't let the build issues dissuade you from adopting XP, Scrum or any of the other methodologies, or even concocting your own in-house agile processes. For the most part, development organizations have seen success with agile methods. The trick is to remain focused on the objectives, mainly reducing development time while improving software quality. Even if compromises on build frequency become necessary, don't lose sight of the need for constant testing, testing, testing.

In fact, if there's one part of the development infrastructure that needs beefing up, it's typically the version-control or source-code-control system. Without good systems, as well as the discipline to use them, changes can be lost, files can be overwritten, and time can be wasted tracking down bug artifacts. While agile methodologies are all about empowering the people—the development team—just make sure you have the build and source-control tools to make it all work.

Otherwise, you won't be truly agile at all. I

It's Not Too Late to Learn

On Feb. 3, 2005, Robert S. Mueller III, director of the Federal Bureau

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.